![[レポート] データファクトリーの構築：汎用ETLパイプラインユーティリティのケーススタディ – Subsurface LIVE Summer 2021](https://devio2023-media.developers.io/wp-content/uploads/2021/07/subsurface-live-logo_1200x630.png){kind=logo}
[レポート] データファクトリーの構築：汎用ETLパイプラインユーティリティのケーススタディ – Subsurface LIVE Summer 2021
米国時間2021年07月21日〜22日の計2日間、オンラインで開催された「Subsurface LIVE Summer 2021」では、主催となるDremio社のサービスやクラウドデータレイクに関する各種サービスやプロダクトのセッションが展開されていました。
当エントリでは、その中から「Building a Data Factory: A Generic ETL Pipeline Utility Case Study」(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)というセッションについてレポートします。
目次
セッション概要
セッション概要は以下の通り。
Building a Data Factory: A Generic ETL Pipeline Utility Case Study
(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)
＜登壇者＞
Matt Topol - Principal Software Engineer @ FactSet Research Systems, Inc.
William Whispell - Principal Software Engineer @ FactSet
＜発表内容＞
FactSet, a leading provider of content in financial services, is focused on continuously improving our data pipeline and data fetch APIs. Most pipeline utilities like Flink and Spark require writing code to their API to define the pipeline, and to cover the breadth of content we offer, various departments have had to write custom ETL code for adding value at various parts of the content enrichment process. In order to standardize and simplify this common workflow, we decided to create a configuration file-based utility that still gives us the granular control we need, but allows encapsulation of the data movements and flows in centralized config files, reducing or eliminating the disparate custom ETL scripts. This case study will examine why we chose to leverage Golang and Apache Arrow to mix new data with our legacy sources and existing stack as we modernize our fetch code paths, and discuss other technologies we leveraged in order to do so.
(金融サービスのコンテンツを提供するリーディングカンパニーであるファクトセットは、データパイプラインとデータフェッチAPIの継続的な改善に注力しています。FlinkやSparkのようなほとんどのパイプラインユーティリティーは、パイプラインを定義するためにAPIにコードを書く必要があります。また、当社が提供する幅広いコンテンツをカバーするために、様々な部門がコンテンツエンリッチメントプロセスの様々な部分で付加価値をつけるためのカスタムETLコードを書かなければなりませんでした。この共通のワークフローを標準化、簡素化するために、設定ファイルベースのユーティリティーを作成することにしました。このユーティリティーでは、必要なきめ細かな制御が可能であると同時に、データの動きやフローを集中的な設定ファイルにカプセル化することができるため、バラバラのカスタムETLスクリプトを削減、または排除することができます。このケーススタディでは、データ取得のコードパスを近代化する際に、新しいデータをレガシーソースや既存のスタックと混合するために、GolangとApache Arrowを活用することを選択した理由を検証し、そのために活用した他のテクノロジーについても説明します。)
セッションレポート
ここからはセッションレポートとなります。それぞれのトピックに関して要点をまとめる形で紹介。
コンテキストの共有
- ETFと投資信託のスクリーナーを6ヶ月で構築
- 複数の異なるデータソースからデータを組み合わせる
- FactSet社の保持するデータの種類
- ミューチュアル・ファンド：FactSetが収集した投資信託の基本的なメタデータ
- ETFs: FactSet社が収集・管理するETFの基本的なメタデータ
- パフォーマンス。アナリティクスチームが算出したリターンデータ
- アグリゲート 構成銘柄のESGデータを集計したもの
- ホールディングス： ファンドの構成銘柄に関するデータ
技術的要件
- 重複の削減とオーダーメイドのスクリプト
- データの正規化・非正規化の容易化
- 独自のデータプロバイダーの仮想化
- データの変換や移動の監査可能性
- ポリグロット・パーシスタンス
- パフォーマンス
- ...再利用可能なものを作ろう！
直面していた課題
- 技術面での制約
- EKSとEMRはコスト面で承認が必要
- 一般的なコストの問題
- 現在のオンプレミスのETLコストは、異なるチーム間でサイロ化されている
- 真のコストが見えない状況
- サードパーティのソリューションを評価し、交渉する時間が限られている
- 6ヶ月のイノベーションプロジェクト
- 現在のオンプレミスのETLコストは、異なるチーム間でサイロ化されている
- 開発者の経験と現在の状況
- 大半のチームがカスタムメイドのETLスクリプトを実行している
- 多種多様な言語で書かれたカスタムスクリプト
自作するか、既存ツールやサービスを使うか
- ソリューションごとの様々なトレードオフがあり、悩ましい
- laC vs ロー/ノーコードソリューション
- 拡張性
- コネクタの制限
- 言語の制限
- コスト
- 今回の要件を満たすようなツールやサービスをざっと列挙するだけでも以下のようなものがあった
- Apache Kafka
- AWS DMS
- debezium
- Apache Airflow
- Azure Data Factory
- Apache Beam
- Apache Flink
Data Factory：データパイプライン
- YAMLを使った設定ベースのパイプライン
- コンシューマ向けのコードレスソリューション
- エンジニアのためだけではない
- 並列化されたデータフローのストリーミング
- パフォーマンス
- リリース時のDockerとバイナリ実行ファイル
- 使いやすさ
- ニーズに応じた開発の進化
- すべてを実現しようとしない
- 例：Sparkのようなものを置き換えるものではない
- すべてを実現しようとしない
- 参考サービス・技術
- Golang
- Apache Arrow
- Parquet
Data Factory：コンポーネント
- コネクタ
- ソース
- シンク
- トランスフォーム
- トランスポート
- チャンネル
- ランタイム環境
- ローカル／リモート
- Linux / Windows
- フォーマット(入力／出力)
- Apache Arrow レコードバッチ
- Apache Parquet
- CSV
- etc...
Data Factory：パイプラインの構成
- コードからデータセットを抽象化する
- viper · pkg.go.dev
- 環境変数を使って設定を簡単に変更できる
- デフォルト値を簡単に定義できる
- コネクタは設定のサブツリーを受け取る
- 環境プレフィックスのサポート
Data Factory：Golang Concurrency(同時実行)の活用
- Golangチャンネルによるコネクタ間の並列・同期転送
- コネクタのシンプルなインターフェース
- コネクタを変更することなく、処理中の実装と他の実装を簡単に入れ替えられる
- コネクタは同時並行で動作し、上流のパイプで次のバッチを閉じるまでブロックする
- コネクタは必要に応じてステートレスまたはステートフルにすることが可能
Data Factory：エラー処理
- Golang Context オブジェクトを使用して迅速に失敗する
- ロギング
- メッセージの受け渡し
実装上の課題
- Performant Golang Parquetライブラリ
- 独自に作成したものであり、現在公式Apacheリポジトリに展開中
- Dremioクライアントの読み取りタイムアウト
- フォーマット機能の処理
- Apache Hudi でのParquetファイルの使用
- Nullのあるリスト
- 2レベルと3レベルのParquetリストのフォーマット
- マップの論理型
- ElasticSearch
- JSONへの変換
- ネストしたカラムタイプを持つCSV
- Apache Hudi でのParquetファイルの使用
現在の制限事項
- チェックポイント機能なし
- バッチ式ウィンドウモデル
- バッファリングに関する基本的な調整のみ
- 変換の対象がバッチレコードに限定されている
今後の予定
- コードのオープンソース化
- コネクタの追加
- DynamoDB
- Golangのsql/dbインターフェイスをドライバで広くサポート
- 他のウィンドウ・モデル
- 設定ファイル作成・閲覧・編集のためのUI
- ビジネスニーズに応じた自動化／プラットフォーム化
- ETL設定の全社的なリポジトリ
- ソース及びシンクとして、Apache Arrow Flightを使用
- シングルプロセスではなく分散モデルへ
まとめ
という訳で、クラウドデータレイクイベント『Subsurface LIVE Summer 2021』のセッション「Building a Data Factory: A Generic ETL Pipeline Utility Case Study」(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)のレポートでした。
FactSet社の取り組みは、ETLを作成・管理・展開していく人々に取って立ちはだかる課題・壁であり、上手いこと解決させたいテーマでもあると言えます。今後の展開としてオープンソース化も視野に入れているようなので、新しい動きに期待したいところですね。
![[参加レポート] 第26回クラウド女子会 AWS BuilderCardsをプレイしよう #cloudgirl #jawsug](https://devio2024-media.developers.io/image/upload/v1730540918/user-gen-eyecatch/vf89er8xbjntpesixv4u.png)
![[イベント開催レポート] Toranomon Tech Hub#1 ~好きなクラウドサービス紹介 LT大会~ #tora_tech](https://devio2024-media.developers.io/image/upload/v1729165103/user-gen-eyecatch/b0lzw9esh7u7z7izkcmd.png)
